29장. 도메인이 서버까지 도달하기까지 — DNS의 이해

이 장에서 말하고자 하는 것

지금까지 우리는 서버를 어디에 두는지,
어떤 네트워크에 연결하는지를 다뤘다.

하지만 정작 사용자가 우리 서비스를 사용할 때는
서버의 IP 주소를 입력하지 않는다.

https://example.com

이렇게 도메인을 입력한다.

그러면 어떻게 이 이름이
실제 서버까지 도달할 수 있을까?

이 질문에 답하는 시스템이

DNS (Domain Name System)

다.

DNS는 우리가 만들 MSA에서 가장 바깥쪽,
즉 “서비스의 입구” 에 해당한다.

1. 사용자는 IP 주소를 외우지 않는다

서버는 결국 IP 주소로 식별된다.

3.36.124.10

하지만 사람은 숫자를 외우기 어렵다.
또 서버 IP는 바뀔 수도 있다.

그래서 사람이 외울 수 있는 이름을 쓴다.

example.com
shop.example.com
api.example.com

이 이름을 다시 IP로 바꿔주는 역할이
DNS의 핵심이다.

2. DNS는 전화번호부와 같다

DNS의 동작을 한 줄로 요약하면 이렇다.

이름을 받아 주소를 돌려준다

example.com      → 3.36.124.10
api.example.com  → 13.124.55.21

전화번호부에서 사람 이름을 보고
번호를 찾는 것과 같은 구조다.

3. DNS는 한 곳에 있지 않다

여기서 많은 사람이 오해한다.

DNS는 어딘가에 있는 하나의 서버가 아니다.

DNS는 여러 단계로 나뉜 계층 구조다.

루트(.)
 └─ TLD (.com / .net / .kr)
     └─ 권한 있는 네임서버 (example.com)
         └─ 레코드 (api.example.com = 13.124.55.21)

이 구조 덕분에 전 세계 도메인을
한 군데에서 관리하지 않고도 답을 찾을 수 있다.

4. 우리 컴퓨터는 어떻게 답을 받는가

사용자가 브라우저에 도메인을 입력하면
다음 흐름이 일어난다.

1. 브라우저 캐시 확인
2. OS 캐시 확인
3. 리졸버(통신사 DNS 등)에 질문
4. 리졸버가 루트 → TLD → 권한 네임서버 순서로 추적
5. 최종 IP를 받아 사용자에게 전달

여기서 중요한 개념이

리졸버 (Resolver)

다.

리졸버는 사용자를 대신해서
DNS 계층을 따라 답을 찾아주는 중간자다.

대부분의 답은 캐시에 들어 있어서
실제 모든 단계를 매번 거치지는 않는다.

5. TTL — 캐시는 얼마나 유지되는가

DNS 응답에는 TTL (Time To Live) 이 함께 붙는다.

TTL은 이 답을 얼마나 캐시에 보관할지를 의미한다.

TTL 60   → 60초 동안 캐시
TTL 3600 → 1시간 동안 캐시

TTL이 길면

응답이 빠르다
변경 반영이 느리다

TTL이 짧으면

변경이 빨리 반영된다
매번 조회가 늘어난다

운영 환경에서는 이 균형이 중요하다.

6. DNS 레코드의 종류

DNS는 IP만 알려주는 게 아니다.

레코드	의미
A	도메인 → IPv4 주소
AAAA	도메인 → IPv6 주소
CNAME	도메인 → 다른 도메인 (별칭)
MX	메일 서버
TXT	임의의 텍스트 (SPF, 인증 등)
NS	이 도메인을 책임지는 네임서버

AWS 환경에서는 여기에
ALIAS 라는 AWS 전용 레코드가 추가된다.

ALIAS는 CNAME과 비슷하지만
CloudFront, ALB, S3 같은 AWS 리소스를
직접 가리킬 수 있다는 점이 다르다.

이건 30장에서 자세히 다룬다.

7. 도메인 등록자와 DNS 호스팅은 다르다

많은 사람이 헷갈리는 부분이다.

도메인을 사는 곳과
DNS를 운영하는 곳은 같을 수도 다를 수도 있다.

도메인 등록자 (Registrar)
  → 도메인 이름의 소유권을 관리한다
  → 예: 가비아, GoDaddy, Route 53 Domains

DNS 호스팅 (DNS Hosting)
  → 그 도메인의 레코드를 실제로 응답한다
  → 예: Route 53, Cloudflare DNS

운영에서는

도메인은 가비아에서 사고
DNS는 Route 53에서 운영한다

같은 구성이 흔하다.

이걸 가능하게 하는 게
NS (네임서버) 레코드다.

등록자에 “이 도메인의 DNS는 Route 53이 책임진다” 라고
지정해 두면 그 뒤로는 Route 53이 응답한다.

8. 우리 MSA에서 DNS는 어디에 있나

이 책에서 만들어 갈 척추 그림을 다시 보자.

사용자 → CloudFront → API Gateway → ALB → ECS → DB

사용자가 가장 먼저 닿는 지점은
실제로는 CloudFront가 아니다.

DNS다.

사용자
  ↓ "api.example.com 어디야?"
DNS (Route 53)
  ↓ "이 CloudFront 주소로 가"
CloudFront
  ↓ ...

즉 DNS는

우리 MSA의 가장 첫 번째 점

이다.

여기서 어디로 보낼지 잘못 결정하면
뒤에 무엇을 잘 만들어도 닿지 않는다.

9. 직접 확인해보기 — CLI로 DNS 들여다보기

DNS 응답은 명령줄에서 바로 볼 수 있다.

dig 명령

dig example.com

응답에 다음이 들어 있다.

;; ANSWER SECTION:
example.com.   300   IN   A   93.184.216.34

300 → TTL
A → 레코드 타입
93.184.216.34 → 실제 IP

특정 레코드만 조회

dig api.example.com A
dig example.com NS
dig example.com TXT

어떤 리졸버를 거쳤는지 확인

dig @8.8.8.8 example.com

이렇게 하면 Google 공용 DNS를 직접 사용해 조회한다.

이 명령들을 외울 필요는 없다.

다만 도메인이 동작하지 않을 때
“DNS 단계에서 답이 잘못 오는지” 를
가장 먼저 확인할 수 있다는 점이 중요하다.

10. 미리 보는 Route 53 — 코드로는 이렇게 생겼다

30장에서 본격적으로 다룰 Route 53을
미리 한 번만 들여다보자.

Terraform으로 표현하면 이렇다.

resource "aws_route53_zone" "main" {
  name = "example.com"
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  records = ["13.124.55.21"]
}

지금은 이해하지 않아도 된다.

다만 우리가 콘솔에서 클릭하든
이렇게 코드로 작성하든
결국 만들어지는 결과는 같다는 것만 기억하자.

11. 이렇게 쓰면 망한다 — DNS 안티패턴

안티패턴 1. TTL을 너무 길게 둔다

TTL = 86400 (하루)

장애가 났을 때 IP를 바꿔도
하루 동안 옛 IP로 가는 사용자가 생긴다.

운영 서비스의 핵심 레코드는
60초 ~ 300초 정도로 시작하는 게 일반적이다.

안티패턴 2. 도메인 최상위에 CNAME을 단다

example.com → CNAME → my-loadbalancer-xxx.elb.amazonaws.com

DNS 표준상 도메인 최상위(apex)는 CNAME을 가질 수 없다.

AWS에서는 이 문제를 해결하기 위해
ALIAS 레코드를 제공한다.

안티패턴 3. DNS 제공자를 여러 곳에 섞어 쓴다

NS 일부는 가비아 / 일부는 Route 53

이러면 사용자에 따라 다른 답을 받아서
“누구는 되는데 누구는 안 되는” 장애가 생긴다.

한 도메인은 한 DNS에서만 응답해야 한다.

안티패턴 4. DNS만으로 로드 밸런싱을 하려고 한다

api.example.com → IP A
api.example.com → IP B

DNS 라운드 로빈으로는

헬스 체크가 불완전하고
캐시 때문에 트래픽이 고르게 분산되지 않으며
장애 서버를 빠르게 빼낼 수 없다

이건 ALB의 일이지 DNS의 일이 아니다.

12. 한 줄로 정리

DNS는 사용자가 가장 먼저 닿는 시스템이며
도메인을 IP로 바꿔 우리 인프라의 입구로 안내하는 역할을 한다

13. 이 장의 핵심 정리

사용자는 IP가 아니라 도메인으로 서비스를 찾는다.
DNS는 이름을 IP로 바꿔주는 계층 구조의 시스템이다.
리졸버와 캐시 덕분에 모든 조회가 매번 전 세계를 도는 것은 아니다.
TTL은 응답을 얼마나 캐시에 둘지를 정한다.
도메인 등록자와 DNS 호스팅은 다른 개념이다.
AWS에서는 DNS 운영을 위해 Route 53을 사용하며, 다음 장에서 자세히 다룬다.
DNS는 우리 MSA의 가장 첫 번째 점이다.

Keyboard shortcuts

AWS로 이해하는 클라우드 컴퓨팅 기초